Design programs for interactive graphical designs, such as web sites, allow users to specify designs while the designs are being rendered in a design environment. The underlying data structure used to render the editable version of the design in the design environment is generally in a different format than the underlying data structure that will be used to render the design itself in a player, such as a web browser. One basic reason that the formats differ is that the editable version of the design and the design itself expose different kinds of interactivity to the user: the editable version exposes interactivity that allows the user to specify and edit the design; and the design itself exposes interactivity to allow the user to interact with the design. For example, selecting a button in the editable version of a design (e.g., via the design environment) will move the focus of the design tool to the button in order to move the button or change its style, while selecting the same button in the rendered version of the design (e.g., via the player) will load a different page of the design. Another reason that the formats differ is that design environments are often proprietary tools while the designs created in said design environments are meant to be distributed widely to numerous potential players. As such, designs are often generated or exported from design environments in standard formats such as via code in a hypertext markup language.
Issues arise when designs are transferred back and forth between a design environment and player during production because certain aspects of the design are for production purposes only and might interfere with the interactivity of the design. For example, design annotations used to communicate potential changes to the design between members of a team that are collaborating on the design can be difficult to implement in the format of the exported design without interfering with the interactivity of the design. Annotations are particularly challenging in situations where the exported design is rendered using a markup language encoding because of the way standard players render markup language designs. Annotations are usually drawn over a design, but because of the way standard players render markup language designs, the annotations effectively block the interactivity of the design. In particular, hypertext markup language does not support interacting with portions of a design that have overlapping elements or containers. As a result, the production design either doesn't provide adequate room for annotations or doesn't allow full interactivity with the design.
FIG. 1 illustrates rendering 101 of an interactive graphical design being rendered in a player 100 such as a web browser. The interactive graphical design includes several design elements such as a hero image 102, a menu of links 103, and a member login form 104. These elements could have been laid out in a graphical design environment by a designer using a drag and drop paradigm. Once the designer has completed the design, another member of the design team could review and annotate the design with annotation 105. Unfortunately, when annotation 105 is exported from the design environment as HTML for rendering in a browser, the curve of annotation 105 will be rendered as element 106, which has a footprint on the page as illustrated in FIG. 1 by a dashed line. Due to the limitations of rendering markup-coded representations of a design in standard browsers, the resulting element will cover button 108, and selection of button 108 will no longer be possible when annotation 105 is rendered with the design. As a result, the rendering of annotation 105 results in a loss of design interactivity which will hinder further review.